-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Elastic-Agent] Make monitoring settings configurable by fleet #17855
Merged
michalpristas
merged 8 commits into
elastic:master
from
michalpristas:agent-config-fleet
Apr 22, 2020
Merged
[Elastic-Agent] Make monitoring settings configurable by fleet #17855
michalpristas
merged 8 commits into
elastic:master
from
michalpristas:agent-config-fleet
Apr 22, 2020
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Pinging @elastic/ingest-management (Project:fleet) |
ph
changed the title
[Agent] Make monitoring settings configurable by fleet
[Elastic-Agent] Make monitoring settings configurable by fleet
Apr 21, 2020
ph
approved these changes
Apr 21, 2020
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, I've looked through the code and the changes LGTM, One thing missing is we need to be able to unit tests theses scenarios. We can do it in another PR.
michalpristas
added a commit
to michalpristas/beats
that referenced
this pull request
Apr 22, 2020
…ic#17855) [Elastic-Agent] Make monitoring settings configurable by fleet (elastic#17855)
6 tasks
ph
pushed a commit
that referenced
this pull request
Apr 22, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
enhancement
needs_backport
PR is waiting to be backported to other branches.
review
[zube]: In Review
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this PR do?
This PR performs (a bit more complicated to review) refactor where it goes from monitor per app to central monitor as initial idea of having option for each app to be monitorable or not is not planned. Now we have central setting saying monitor or not.
This central monitoring component holds information about whether monitor or not or which part do we need to monitor (logs/metrics).
On config change state of this component is updated first and then applications will pick them up and act accordingly.
Reload is also happening when config is coming from fleet. Up until now it as static setting on load which operator was fed at the start time.
Why is it important?
To enable setting this config from fleet and change the value during runtime.
Checklist
CHANGELOG.next.asciidoc
orCHANGELOG-developer.next.asciidoc
.By default monitoring beats are feeding
metricbeat-{version}-{date}
orfilebeat-{version}-{date}
indices. When testing in standalone (using default credentials) this works correctly with fleet we lack permissions on these and publishing fails:^^ cc @nchaulet
I tested few scenarios:
Test 1:
Standalone, monitoring enabled
Result: starts FB and MB, indices created and with data
Test 2:
Standalone, monitoring disabled
Result: monitoring not started, indices not created
Test 3
Standalone, monitoring disabled to enabled (reload test)
Result: initially nothing started, after config change starts FB and MB, indices created and with data
Test 4:
Fleet, monitoring disabled
Result: monitoring not started, indices not created
Test 5:
Fleet, monitoring enabled
Result: starts FB and MB, indices NOT created
FAILS on permissions
edit:
after modifying index changes are
Test 5:
Fleet, monitoring enabled
Result: starts FB and MB, indices created with data